昨天說學習路徑的第 2 步是「本機起一個真的叢集」。今天動手：在一台 Ubuntu VM 上裝 k3s。
我選 k3s 而不是 minikube，原因很單純：我的開發機本身就是一台雲端 VM（GCP e2-standard-8、Spot），k3s 是單一 binary、直接跑在主機上，不需要再套一層虛擬化。
先講清楚：這篇的指令是我照官方安裝流程整理的，寫這篇時還沒在乾淨的 VM 上從頭重跑一次驗證（front matter 標了 verified: false）。你照做時遇到差異，請以官方文件為準。
curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get nodes
第一行下載並安裝 k3s，同時註冊成 systemd 服務（k3s.service），開機會自動啟動。第二行確認節點 Ready。
k3s 自帶 kubectl，用 sudo k3s kubectl 呼叫。如果你想直接打 kubectl，把 /etc/rancher/k3s/k3s.yaml 複製到 ~/.kube/config 並改權限即可，記得別把這個檔案 commit 進 repo。
k3s 需要 cgroup v2，或是設定正確的 cgroup v1。在較新的 Ubuntu 上通常沒問題；如果你的 VM 是舊 image，或跑在某些容器化環境裡，k3s.service 會起不來，journalctl -u k3s 裡會看到 cgroup 相關錯誤。
解法依環境不同，這裡我不裝懂：先看 journal，再對照官方的 Requirements 頁面。
k3s 本身很輕，但「輕」是相對的。我的經驗是：在一台已經跑著十幾個 Docker 容器、幾個 AI agent session 的機器上再疊一個 k3s，你要先確認 available memory 還有餘裕。
Day 04 講過我的開發機被多個 session 疊加壓到 swap 見底的實錄。如果你的機器已經在那個狀態，先清空間再裝，不然 k3s 的 control plane 元件會跟你的 agent 互搶記憶體，兩邊都不好過。
具體門檻我不寫數字（官方 Requirements 頁有列，而且會隨版本變）。一個實用的判斷：free -h 看 available 那欄，如果它已經低於你打算給叢集裡工作負載的總量，就不要硬裝。
這是我最在意的一點，因為我的開發機是 Spot VM，2026-09-07 才真的重開過一次。
k3s 註冊成 systemd 服務這件事在這裡很關鍵：VM 重開後 k3s.service 會自動起來，之前 apply 進去的 Deployment 還在（狀態存在 k3s 內建的 SQLite 裡，不是記憶體），controller 會把缺的 Pod 補回來。前提是 /var/lib/rancher/k3s 所在的磁碟還在：我的開機碟重開不會消失；VM 整台重建、或狀態放在 ephemeral disk 就另當別論。
對比一下 Day 18 會講的實錄：同一次重開，我用 tmux 跑的那些 agent session 要靠一套自己寫的還原腳本才回得來，而且還部分失敗了；Docker 容器則靠 restart policy 自己回來。k3s 屬於後者那一類，宣告過的狀態會自己回來，這正是我想學它的原因之一。
sudo k3s kubectl get pods -A
sudo k3s kubectl run hello --image=nginx --restart=Never
sudo k3s kubectl wait --for=condition=Ready pod/hello --timeout=120s
sudo k3s kubectl get pod hello
sudo k3s kubectl delete pod hello
第一行會看到 kube-system 底下的東西：長駐元件（coredns、traefik 等）應該是 Running，helm-install-* 顯示 Completed 是正常的；剛裝完要等一下，不是馬上全綠。中間三行跑一個最小的 Pod、等它 Ready、再看狀態，確認排程與 image pull 正常；最後一行清掉。
明天把一隻真的 bot 搬進來。
k3s 讓「叢集」這個詞從一個大工程變成一個 systemd 服務；重開機它自己回來，這件事本身就值得你花 10 分鐘。
iThome鐵人賽
看影片追技術